Thank you for contributing to Miri! A reviewer will take a look at your PR, typically within a week or two.
Please remember to not force-push to the PR branch except when you need to rebase due to a conflict or when the reviewer asks you for it.

Thanks for the PR!

However, before we do anything like this and risk papering over a deeper problem, we need to figure out why this code isn't rejected by rustc. Generic no_mangle items make no sense. Why is that not a hard error?

The lint dates back to rust-lang/rust#30269 and I've been unable to find any conversation about the decision to make it a warning. IMO the most sensible thing here is a hard error, the compiler ignoring #[no_mangle] seems really bad.

Yea, we should just crater turning the lint into an error

for this kind of language change(warn -> error), should i create a rfc firstly? sorry i am a new comer of rust community.

You can open a PR for rustc directly. You can assign it to me with r? @oli-obk in the main PR message or a comment.

I'll crater it (run it on all crates on crates.io), and then will send it to the lang team for FCPing it. This change doesn't need an RFC

I'll mark this PR as waiting-on-author then while alternative avenues are being explored.

@rustbot author

Reminder, once the PR becomes ready for a review, use @rustbot ready.

I just ran into the same ICE in #5128, without realizing it, and wrote a fix in #5129. My fix filters out generics earlier, inside iter_exported_symbols, which I think is preferable. I will hence close this PR, but I'll cherry-pick your test so that this is not just tested by test-cargo-miri.